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REMARKS/ARGUMENTS 

The Office Action mailed August 25, 2006, has been carefiiUy considered. 
Reconsideration in view of the following remarks is respectfiilly requested. 

Claims 12-44, 46, and 51-70 are currently pending. No claims are allowed. 

Claims 12, 16, 18, 25, 29, 31, 38, 39, 40, 41, 46, and 47 have been amended to further 
particularly point out and distinctly claim subject matter regarded as the invention. Support for 
these changes maybe found in the specification, figures, and claims as originally filed, 
specifically nil 10, 16, 20, and 46, and FIG. 1. The text of claims 13-15, 17, 19-24, 26-28, 30, 32- 
37, 43-44, and 50 is unchanged, but their meaning is changed because they depend from 
amended claims. 

Claims 1-11, 45, and 48-49 have been previously canceled, without prejudice or 
disclaimer of the subject matter contained therein. 

New claims 51-70 also particularly point out and distinctly claim subject matter regarded 
as the invention. Support for these claims may be found in the specification, figures, and claims 
as originally filed, specifically Iffl 10, 12, 16, 20, 40, 41, 46, and 48, and FIG. 1. 

With this Amendment it is respectfully submitted the claims satisfy the statutory 
requirements. 
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The 35 U,S,C. S 102 Rejection 

Claims 12-42, 44, 46-47, and 50 were rejected under 35 U.S.C. § 102(e) as being 
allegedly anticipated by Tang, et al. ^ ^ Tang et al. incorporates by reference Gleeson et al. ^ This 
rejection is respectfully traversed. 

According to the M.P.E.P., a claim is anticipated under 35 U.S.C. § 102(a), (b) and (e) 
only if each and every element as set forth in the claim is found, either expressly or inherently 
described, in a single prior art reference."^ 



Claim 12 

Claim 12 as presently amended recites: 

A method for handling a control message in a Virtual Local Area Network 

(VLAN), the method comprising: 
receiving a control message at a layer 2 switch of said VLAN, said control 

message sent by a layer 3 router; 
updating a source-group data structure using information from the control 

message, the source-group data structure containing data regarding a 

multicast group; and 
adding an outgoing port index to said source-group data structure, said outgoing 

port index identifying a port that received the control message. 

The Examiner states: 

... Gleeson shows a method comprising: updating a source-group data structure 
using information from the control message, the source-group data structure 
containing data regarding a multicast group [See Fig. 2c of Gleason, which is a 
"source-group data structure." It contains multicast group address. See lines 21- 
32 in column 2 of Gleason. See lines 30-35 in column 16 for the step of updating 
the data structure]; and adding an outgoing port index to data source-group data 
structure, said outgoing port index identifying a port that received the control 
message [See Fig. 2C, which lists a port index Cport number') in the table. 



* U.S. Patent No. 6,839,348 to Tang et al. 

^ Office Action dated August 25, 2006, at p. 4. 

^ U.S. Patent No. 5,959,989 to Gleeson et al. 

^ Manual of Patent Examining Procedure (MPEP) § 2131. See also Verdegaal Bros, v. Union Oil Co. of California, 
814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). 
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Inserting the source group necessarily adds a port number, because the data 
structure includes a field for the "port index."]. ^ 

The Applicants respectfully disagree for the reasons set forth below. 

Tang et al. and Gleeson et al. speak generally about creating a special label or tag for 
multicast packets. As pointed out in the Background section of the Application as filed, although 
tag switching enables a layer 3 router to read the tag and forward the packet, the router must be 
specially configured to interpret the tag.^ Whereas embodiments of the invention as presently 
claimed intelligently implement layer 2 switching among multiple input/output ports that are 
connected to neighboring devices such as routers. Protocol snooping limits the multicast content 
to only those routers, within a VLAN, that require the content, hitelligent forwarding is based on 
information learned from control messages exchanged between multicast routers, thus obviating 
the need for any specialized tagging technique. With this Amendment, independent claims 12, 
16, 18, 25, 29, 31, 38, 39, 40, 41, and 46 have been amended to make this distinction more clear. 
Specifically, the independent claims have been modified to recite handling a control message in a 
Virtual Local Area Network (VLAN), and receiving a control message at a layer 2 switch of said 
VLAN, said control message sent by a layer 3 router. For this reason, the 35 U.S.C. § 102 
rejection of Claim 12 based on Tang et al. is unsupported by the art and must be withdrawn. 

Moreover, Gleeson et al. discloses processing messages from the Clients (sources); the 
reference does not disclose processing control messages firom a router. Whereas Claim 12 
requires that the source-group data structure is built from control messages sent from one 
multicast router to another multicast router through the switch. For this additional reason, the 35 
U.S.C. § 102 rejection of Claim 12 based on Tang et al. is unsupported by the art and must be 
withdrawn. 

^ Office Action at pp. 4-5. 
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Claims 13-15 

Claims 13-15 depend from Claim 12. The base claim being allowable, the dependent 
claims must also be allowable. 



Claim 15 

Claim 15 recites: 

The method of Claim 12, further comprising: 

searching in a forwarding table for a forwarding entry having a destination 

hardware address matching a destination hardware address for a multicast 

group indicated by the control message; and 
updating said forwarding entry in said forwarding table if a destination hardware 

address matching a destination hardware address for said multicast group is 

found. 

The Examiner states: 

... Tang shows searching in a forwarding table for a forwarding entry having a 
destination hardware address matching a destination hardware address for a 
multicast group indicated by the control message [See from line 35, column 15 to 
line 3 in column 16 of Tang]; and updating said forwarding entry in said 
forwarding table if a destination hardware address matching a destination 
hardware address for said multicast group is found [See from line 35, column 15 
to line 3 in column 16 of Tang]. 

The Applicants respectfiilly disagree. The arguments made above with respect to Claim 12 apply 

here as well. The portion of Tang et al. referenced by the Examiner refers to the operation of a 

layer 3 router, not a layer 2 switch as required by Claim 15. For this additional reason, the 35 

U.S.C. § 102 rejection of Claim 15 based on Tang et al. is unsupported by the art and must be 

withdrawn. 



^ Specification, Background Section, H 6. 
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Claim 16 

Claim 16 as presently amended recites: 

A method for handling a control message in a Virtual Local Area Network 

(VLAN), the method comprising: 
receiving a control message at a layer 2 switch of said VLAN, said control 

message sent by a layer 3 router; 
deriving an explicit source lookup key from the control message; 
retrieving an outgoing port index associated with an entry in a session data 

structure, said entry corresponding to said explicit source lookup key; and 
updating an outgoing lookup table entry corresponding to said outgoing port index 

with information regarding designated devices in said multicast group 

indicated by the control message. 

The Examiner states: 

... Tang and Gleeson show a method comprising deriving an explicit source 
lookup key from the control message [See lines 50-67 in column 16 of Tang. S4, 
which is the specific source address, is the "source lookup key."]; and retrieving 
an outgoing port index associated with an entry in a session data structure, said 
entry corresponding to said explicit source lookup key ["Session data structure" 
are the rows, in the multicast routing table ("forwarding table"). Each entry of the 
outgoing interface list is associated with an interface ("outgoing port index") 
shown in Fig. 3. The retrieval is performed by looking up the forwarding table]; 
and updating an outgoing lookup table entry corresponding to said outgoing port 
index with information regarding designated devices in said multicast group 
indicated by the control message [See Fig. 3 of Tang. The outgoing lookup table 
entry is either ELF or OIF-in the-multicast routing table. It is updated in 
accordance with the; description, starting at line 16, column 16 to line 17, in 
column 19].^ 

The Applicants respectfully disagree. The arguments made above with respect to Claim 12 apply 
here as well. The portion of Tang et al. referenced by the Examiner refers to the operation of a 
layer 3 router, not a layer 2 switch as required by Claim 16. For this additional reason, the 35 
U.S.C. § 102 rejection of Claim 16 based on Tang et al. is unsupported by the art and must be 
withdrawn. 



' Office Action at p. 6. 
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Additionally, contrary to the Examiner's statement, Tang et al. does not disclose deriving 
an explicit source lookup key from the control message. In support of the Examiner's 
contention, the Examiner refers to FIG. 3 of Tang et al. , which is included below for the 
Examiner's convenience. 
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Tang et al. recites: 

To forward the multicast message from entity S4, multicast controller 302 first 
performs a Reverse Path Forwarding (RPF) check on the received message. In 
particular, multicast controller 302 checks to see whether the message was 
received on the interface used to send unicast messages to entity S4 (i.e., the 
yellow VLAN interface), which is also listed in the UF for this {S4, Gl} source- 
specific route entry.^ 

Thus, rather than deriving an explicit source lookup key from the control message as required by 
Claim 16, Tang et al. obtains an incoming port from the incoming interface Hst (IIF) of a 
multicast routing table, where the incoming interface is obtained by performing a reverse path 
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forwarding (RPF) check on the received message. An RPF check is possible in Tang et al. 
because Tang et al. discloses layer 3 processing. Whereas Claim 16 recites processing on a layer 
2 switch, and the tables required to perform such an RPF check are not present on layer 2 
switches. For this reason, the 35 U.S.C. § 102 rejection of Claim 16 based on Tang et al is 
unsupported by the art and must be withdrawn. 



Claim 17 

Claim 17 depends from Claim 16. The base claim being allowable, the dependent claim 
must also be allowable. 



Claim 18 

Claim 18 as presently amended recites: 

A method for handling a control message in a Virtual Local Area Network 

(VLAN), the method comprising: 
receiving a control message at a layer 2 switch of said VLAN, said control 

message sent by a layer 3 router; 
determining if the control message establishes shared source distribution trees or 

expUcit source distribution trees; 
updating a source-group data structure using information from the control 

message, the source-group data structure containing data regarding a 

multicast group, if the control message establishes shared source distribution 

trees; 

adding an outgoing port index to said source-group data structure, said outgoing 
port index identifying a port that received the control message if the control 
message establishes shared source distribution trees; 

deriving an explicit source lookup key from the control message if the control 
message establishes explicit source distribution trees; 

retrieving an outgoing port index associated with an entry in a session data 

structure, said entry corresponding to said explicit source lookup key, if the 
control message establishes explicit source distribution trees; and 

updating an outgoing lookup table entry corresponding to said outgoing port index 
with information regarding designated devices in said multicast group 



^ Tang et al at col. 16 11. 50-56. 
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indicated by the control message if the control message establishes explicit 
source distribution trees. 

The Examiner states: 

... Tang and Gleeson show a method comprising determining if the control 
message establishes shared source distribution trees or explicit source distribution 
trees [The step is inherent in Tang. Tang's system responds differently depending 
on the source address, whether it is shared source distribution tree or it is an 
explicit source distribution tree. If it is a shared distribution tree, the system 
follows the steps described from Une 16, column 15 to line 13, column 16 in 
Tang. If the message is an explicit one. Tang's system follows the steps described 
from line 14, column 16 to line 19, column 19]; Other limitations of claim 18 are 
same as those of claims 12 and 16, with one difference. The limitations which 
correspond to those in claim 12 are different than those of claim 12 because of an 
additional clause, "if the control message establishes shared source distribution 
trees." Gleason still meets the limitations, because the steps (which correspond to 
the limitations of claim 12) apply to both shared source distribution and non- 
shared.^ 

The Applicants respectfiilly disagree. Claim 18 includes limitations similar to Claim 12 and 16. 
Thus, the arguments made above with respect to Claims 12 and 16 apply here as well. 

Additionally, the Applicants respectftilly submit that the rejection of Claim 18 lacks the 
clarity required by the M.P.E.P,*^ The rejection of Claim 18 refers to "other limitations of claim 
18 are same as those of claims 12 and 16," without identifying the precise elements to which the 
Examiner intends to refer. The Examiner is reminded that a proper rejection under 35 U.S.C. § 
102 requires that "[t]he identical invention must be shown in as complete detail as contained in 
the...claim."^^ 

The rejection of Claim 18 also appears to indicate that Tang et al. discloses performing a 
first set of actions only if the control message establishes shared distribution trees, and 



^ Office Action at pp. 6-7. 

See M.P.E.P. § 707.07(f) ("In order to provide a complete application file history and to enhance the clarity of the 
prosecution history record, an examiner must provide clear explanations of all actions taken by the examiner during 
prosecution of an application."). See also M.P.E.P. § 707.07(d) ("Where a claim is refused for any reason relating to 
the merits thereof it should be 'rejected' and the ground of rejection fully and clearly stated, and the word 'reject* 
must be used."). 

Richardson V.Suzuki Motor Co., m¥, 2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir, 1989). See also M.P.E.P. 
§2131. 
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performing a second set of actions only if the control message establishes explicit source 
distribution trees, and further that Gleeson et al discloses performing the first set of actions 
regardless of whether the control message establishes shared source distribution trees or explicit 
source distribution trees. If so, the Examiner's statements reveal one reason why Tang et al. , 
which incorporates Gleeson et al. , does not anticipate Claim 18, is non-enabling, or both. 



Claims 19-24 

Claims 19-24 depend from Claim 18. The base claim being allowable, the dependent 
claims must also be allowable. 



Claims 19-22 

Claims 19-22 include limitations similar to Claims 13-15 and 17. Thus, the arguments 
made with respect to Claims 13-15 and 17 apply here as well. 



Claim 23 

Claim 23 recites: 

The method of Claim 18, further comprising: 

determining if the control message is a hello or join/prune message; and 
performing said determining, updating a source-group data structure, adding, 

deriving, retrieving, and updating an outgoing lookup table entry only if said 

control message is a join/prune message. 

The Examiner states: 

... Tang shows determining if the control message is a hello or join/prune message 
[identification of the message type is inherent in multicast network device in 
Tang. MND's implement PIM protocol. See lines 15-39, colunm 10] and 
performing said determining, updating, a source-group data structure, adding, 
deriving, retrieving, and updating an outgoing lookup table entry only if said 
control message is a join/prune message. [See the above discussion of Tang in the 
preceding claims. All of the preceding functions are only performed when the 
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message is a join message. The 'group forwarding table' 250 in Fig. 2C can only 
be updated upon join/prune, because it requires subscription data changes. 

The Applicants respectfully disagree. Claim 23 requires performing said determining, updating a 

source-group data structure, adding, deriving, retrieving, and updating an outgoing lookup table 

entry only if said control message is a join/prune message, (emphasis added) The Examiner has 

not pointed to where Tang et al. discloses the listed actions are performed only if said control 

message is a join/prune message. 

The Applicants respectfully submit that the Examiner's statement that "[t]he 'group 

forwarding table' 250 in Fig. 2C can only be updated upon join/prune, because it requires 

subscription data changes" does not address the claimed limitations of Claim 23. First, the fact 

that a join/prune requires subscription data changes does not preclude the possibility that another 

event would also require subscription data changes. Secondly, even if the Examiner's statement 

is true, it does not address the requirement that the "deriving" and "retrieving" steps also be 

performed only if said control message is a join/prune message. For these additional reasons, the 

35 U.S.C. § 102 rejection of Claim 23 based on Tang et al. is unsupported by the art and must be 

withdrawn. 

Claim 24 

Claim 24 recites: 

The method of Claim 23, further comprising: 

creating or updating a neighbor list using said hello message, said neighbor list 
identifying address and port information regarding a device which sent the 
control message. 

The Examiner states: 



Office Action at p. 7. 
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With respect to claim 24, Tang's device implements PIM hello [See lines 15-39, 
column 10]. Implementation of hello entails creating or updating a neighbor list 
using said hello message, said neighbor list identifying address ad port 
information regarding device which sent the control message. In other words, the 
limitation merely repeats what any system that implements hello is capable of 
performing. 

The Examiner admits that Tang et al. does not teach creating or updating a neighbor list using 
said hello message, said neighbor list identifying address and port information regarding a device 
which sent the control message, but does not provide a specific reference where such a limitation 
is found, instead arguing that any system that implements PIM hello would perform the recited 
limitation. Therefore, the Applicants assume that the Examiner intended to take official notice of 
facts under M.P.E.P. § 2144.03 that the rationale supporting the rejection is based on common 
knowledge in the art or "well-known" prior art. Under M.P.E.P. § 2144.03, "[i]f the applicant 
traverses such an assertion the examiner should cite a reference in support of his or her position." 
The Applicants hereby traverse the assertion and request that a reference be cited in support of 
the position outlined in the Office Action. 

Claims 25-37 

Claims 25-37 are means-plus-function claims corresponding to method claims 12-24, 
respectively. Claims 12-24 being allowable, Claims 25-37 must be allowable for at least the 
same reasons. 



Office Action at p. 7. 
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Claims 38-40 

Claims 38, 39, and 40 are In re Beauregard claims corresponding to method claims 12, 
16, and 18, respectively. Claims 12, 16, and 18 being allowable, Claims 38, 39, and 40 must be 
allowable for at least the same reasons. 



Claim 41 

Claim 41 as presently amended recites: 

A method for handling a control message in a Virtual Local Area Network (VLAN), the 

method comprising: 
receiving a control message at a layer 2 switch of said VLAN, said control 

message sent by a layer 3 router; 
deriving a shared source lookup key from multicast group information in the 

control message; 

searching a forwarding data structure for a forwarding entry having a shared 

source lookup key matching the shared source lookup key; 
if a forwarding entry having a shared source lookup key matching the destination 

shared source lookup key is found, revising an associated outgoing port in the 

forwarding entry to match an incoming port for the control message; 
extracting multicast group information from the control message; 
updating a source-group data structure with the multicast group information; and 
adding an outgoing port index to the source-group table, the outgoing port index 

identifying a port that received the control message. 

Tang et al. does not disclose receiving a control message at a layer 2 switch of said 
VLAN, said control message sent by a layer 3 router. With this Amendment, Claim 41 has been 
amended to make this distinction more clear. For this reason, the 35 U.S.C. § 102 rejection of 
Claim 41 based on Tang et al. is unsupported by the art and must be withdrawn. 
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Claims 42-44 

Claims 42-44 depend from Claim 41. The base claim being allowable, the dependent 
claims must also be allowable. 



Claim 46 

Claim 46 as presently amended recites: 

A method for handling a control message in a Virtual Local Area Network 

(VLAN), the method comprising: 
receiving a control message at a layer 2 switch of said VLAN, said control 

message sent by a layer 3 router; 
deriving an explicit source lookup key from the control message; 
searching a session data structure for a session entry having an explicit source 

lookup key matching the derived explicit source lookup key; and 
if a session entry having an explicit source lookup key matching the derived 

explicit source lookup key is found, revising an associated outgoing port in 

the session entry to match an incoming port for the control message. 

The Examiner states: 

... Tang shows deriving an explicit source lookup key from the control packet [See 
lines 27-49, column 16. S4 is the source lookup key and it is an address]; 
searching a session data structure for a session entry having an explicit source 
lookup key matching the derived explicit source lookup key ["Session data 
structure" correspond to the rows, in the multicast routing table ("forwarding 
table"). Each entry of the outgoing interface list is associated with an interface 
("outgoing port index") shown in Fig. 3. The retrieval is performed upon 
searching the session data structure. See from lines 27-49, column 16.]; if a 
session entry having an explicit source lookup key matching the derived explicit 
source lookup key is found, revising an associated outgoing port in the session 
entry to match an incoming port for the control message [See Fig. 3 of Tang. The 
outgoing lookup table entry is either IIF or OIF in the multicast routing table. It is 
revised in accordance with the description, starting at line 16, column 16 to line 
17, in column 19.].'"^ 



Office Action at p. 9. 
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Contrary to the Examiner's statement, Tang et al does not disclose deriving an explicit source 
lookup key from the control message. In support of the Examiner's contention, the Examiner 
refers to FIG. 3 of Tang et al. , which is included below for the Examiner's convenience. 



306 



VLANTAG 
SOURCE 



MULTICAST 
CONTROLLER 



^314 316-,^ MULTICAST ROUTING TABLE ^318 320-^ 


squRCE 

ADbR^SS 


MULTICAST GROUP 
DESTINATION 
ADDRESS 


INTERFAQE 
M?T(0|F) 


INCOMING 
LIST fllF) 


♦ 


G1 


R,BL.G 


IRL 


S4 


G1 


R.BL,G 


Y 


S5 


G1 


BL.G 


R 




G2 


R,Bl,G 


IRL 


SI 


G2 


R.BL.G, IRL 


INT. 1 



















31G- 



VIAN ASSlGNMEiNT 
EMGINE 



MULTICAST VLAN 
CONTTROL MESSAGE 
GENERATOR 



IMT. 
1 



INT. 
2 



VL/^ 
INT, 



VLAN 
INT- 
(BL) 



VLAN 
INL 



/<304a i/-304 b |^3( M c |^30 4 <l j/-30 4 e IrZ O Ai Iz-ZO^ Iz-Wh }/'3 0 4l |/-3 Q4j |/-304k 



VLAN 
INT. 
(V) 



VLAN 
INT. 
(0) 



VLAN 
IMT 
(1) 



VLAN 
INT. 
(P) 



VUN 
INT, 
f8R) 



•308 



"326a 
'326b 
'326c 
'326d 
■326e 



h302 
312 



VLAN 
INT. 
(IRL) 



PORT 
1 



TO/FROM Sr 



PORT 
2 



PORT 3 



138c 



TO/FRO^^ S2 



FIG. 3 



-TO/FROM VLAN REGION 102 



G 
ft 

3 



C 



Tang et al. recites: 



To forward the multicast message from entity S4, multicast controller 302 first 
performs a Reverse Path Forwarding (RPF) check on the received message. In 
particular, multicast controller 302 checks to see whether the message was 
received on the interface used to send unicast messages to entity S4 (i.e., the 
yellow VLAN interface), which is also listed in the IIF for this {S4, Gl} source- 
specific route entry. 



Thus, rather than deriving an explicit source lookup key from the control message as required by 
Claim 46, Tang et al obtains an incoming port from the incoming interface list (IIF) of a 
multicast routing table, where the incoming interface is derived by performing a reverse path 
forwarding (RPF) check on the received message. An RPF check is possible in Tang et al. 
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because Tang et al. discloses layer 3 processing. Whereas Claim 47 recites processing on a layer 
2 switch, and the tables required to perform such an RPF check are not present on layer 2 
switches. For this reason, the 35 U.S.C. § 102 rejection of Claim 47 based on Tang et al. is 
unsupported by the art and must be withdrawn. 

Additionally, Tang et al. does not disclose receiving a control message at a layer 2 switch 
of said VLAN, said control message sent by a layer 3 router. With this Amendment, Claim 46 
has been amended to make this distinction more clear. For this additional reason, the 35 U.S.C. 
§ 102 rejection of Claim 41 based on Tang et al. is unsupported by the art and must be 
withdrawn. 

Claims 47 and 50 

Claims 47 and 50 depend from Claim 46. The base claim being allowable, the dependent 
claims must also be allowable. 

Claim 47 

Claim 47 as presently amended recites: 

The method of Claim 46, wherein the explicit source lookup key comprises a multicast 
source network address, a destination network address, an incoming port for the 
control message, and a protocol type. 

The Examiner states: 

. . . Tang shows that the explicit source lookup key is a combination of a multicast 
source network address, a destination network address, and incoming port for the 
control message and a protocol type. See Fig. 3. Any element of each row in the 
multicast routing table maybe used as a key. Note that even though protocol type 



Tane et al. at col. 16 11. 50-56. 
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is not included in the table, Tang's feature still meets the limitation, because the 
limitation does not require the-presence-of the port type. The limitation 
prescribes some "combination" of "source network address, destination network 
address, and incoming port.*^ 

The Applicants respectfully disagree. With this Amendment, Claim 47 has been amended to 
recite the explicit source lookup key comprises a multicast source network address, a destination 
network address, an incoming port for the control message, and a protocol type. This is not 
disclosed by the cited art of record. 



Additionally, contrary to the Examiner's statement, Tang et al. does not disclose the 
explicit source lookup key comprises an incoming port for the control message, hi support of the 
Examiner's contention, the Examiner refers to FIG. 3 of Tang et al , which is included below for 
the Examiner's convenience. 



*^ Office Action at p. 10. 
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Tang et al. recites: 

To forward the multicast message from entity S4, multicast controller 302 first 
performs a Reverse Path Forwarding (RPF) check on the received message. Li 
particular, multicast controller 302 checks to see whether the message was 
received on the interface used to send unicast messages to entity S4 (i.e., the 
yellow VLAN interface), which is also listed in the IIF for this {S4, Gl} source- 
specific route entry. 

Thus, rather than using the incoming port for the control message as required by Claim 47, Tang 
et al. obtains an incoming port from the incoming interface list (ELF) of a multicast routing table, 
where the incoming interface is derived by performing a reverse path forwarding (RPF) check on 
the received message. An RPF check is possible in Tang et al. because Tang et al. discloses layer 
3 processing. Whereas Claim 47 recites processing on a layer 2 switch, and the tables required to 
perform such an RPF check are not present on layer 2 switches. For this reason, the 35 U.S.C. § 
102 rejection of Claim 47 based on Tang et al. is unsupported by the art and must be withdrawn. 
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Claim 50 

Claim 50 recites: 

The method of Claim 46, further comprising: 
extracting multicast group information from the control message; 
updating a source-group data structure with the multicast group information; and 
adding an outgoing port index to the source-group table, the outgoing port index 
identifying a port that received the control message. 

The Examiner states: 

Claim 50 substantively incorporates the limitations of claim 45, and the reasons 
for the rejection of claim 45 apply to claim 50.'^ 

The Applicants note that Claim 45 was previously cancelled. As the rejection of Claim 50 is 

based on a purported rejection of a cancelled claim, there is no basis for rejection of Claim 50. 

Withdrawal of the rejection of Claim 45 is respectfully requested. 

In view of the foregoing, it is respectfully asserted that the claims are now in condition 
for allowance. 

Conclusion 

It is believed that this Amendment places the above-identified patent application into 
condition for allowance. Early favorable consideration of this Amendment is earnestly solicited. 

If, in the opinion of the Examiner, an interview would expedite the prosecution of this 
application, the Examiner is invited to call the undersigned attomey at the number indicated 
below. 



Tang et al. at col. 16 11. 50-56. 
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The Applicants respectfully request that a timely Notice of Allowance be issued in this 
case. Please charge any additional required fee or credit any overpayment not otherwise paid or 
credited to our deposit account No. 50-1698. 



Dated: January 25, 2007 



Thelen Reid & Priest LLP 
P.O. Box 640640 
San Jose, CA 95164-0640 
Tel. (408) 292-5800 
Fax. (408) 287-8040 



Respectfully submitted. 



THELEN REID & PRIEST, LLP 




JohA P. Schaub 
Reg. No. 42,125 



Office Action at p. 10. 
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